Which issue does this PR close?

• Closes Remove redundant partitioned_by_file_group file scan field #23099 .

Rationale for this change

FileScanConfig had two overlapping ways to declare a file scan's output
partitioning:

• partitioned_by_file_group: bool — a shorthand meaning "the file groups are
  organized by Hive partition column values, so the output is Hash-partitioned on
  those columns", and
• output_partitioning: Option<Partitioning> — a general, explicit declared
  partitioning (added in Add ListingOptions::output_partitioning and FileScanConfig::output_partitioning for pre-defined file partitioning #22657).

The bool is just a lazy shorthand for one specific output_partitioning value
(Partitioning::Hash over the partition columns), and every place that consumed
it (output_partitioning(), repartitioned(), create_sibling_state()) already
checked output_partitioning.is_some() || partitioned_by_file_group. Keeping both
is redundant and the ListingTable builder ended up setting both. This PR makes
output_partitioning the single source of truth.

What changes are included in this PR?

Following the issue's first option ("Remove partitioned_by_file_group"):

• Remove FileScanConfig::partitioned_by_file_group, the corresponding
  FileScanConfigBuilder field, and the with_partitioned_by_file_group builder
  method.
• ListingTable::scan now derives the partition-column Partitioning::Hash
  itself (once its file groups are finalized, so the partition count is correct)
  and passes it through the existing with_output_partitioning. The previous
  with_output_partitioning(declared) + with_partitioned_by_file_group(...)
  double-set is collapsed into one branch.
• hash_partitioning_from_partition_fields is made pub so ListingTable
  (a separate crate) can reuse the derivation instead of duplicating the
  column-index resolution.
• proto already round-trips output_partitioning, so no behavior is lost: the
  now-vestigial partitioned_by_file_group wire field is left unset on write and
  ignored on read. The field is kept in the .proto definition for backward
  compatibility.
• output_partitioning() / create_sibling_state() / repartitioned() now key
  solely off output_partitioning.

Are these changes tested?

Yes — by existing tests, updated to the new single-field model:

• datafusion-datasource: test_output_partitioning_with_partition_columns,
  test_output_partitioning_no_partition_columns,
  test_declared_output_partitioning_projects_with_scan, and the file_stream
  work-stealing test morsel_partitioned_by_file_group_keeps_files_local (which
  verifies that a declared output partitioning keeps each stream's files local).
• datafusion-proto: roundtrip_parquet_exec_output_partitioning (and the other
  roundtrip_parquet_exec_* cases) cover the partitioning round-trip. The old
  roundtrip_parquet_exec_partitioned_by_file_group test exercised the removed
  API and is dropped, as its coverage is subsumed by the output_partitioning
  round-trip test.

All of the above pass, along with cargo fmt --all --check and
cargo clippy --all-targets --all-features -- -D warnings for the affected
crates.

Are there any user-facing changes?

Yes — public API changes :

• Removed: the public FileScanConfig::partitioned_by_file_group field and the
  FileScanConfigBuilder::with_partitioned_by_file_group method. Callers should
  set with_output_partitioning(Some(Partitioning::Hash(..))) instead (or use the
  now-public hash_partitioning_from_partition_fields helper).
• Added: hash_partitioning_from_partition_fields is now pub.

Query results, optimizer decisions (e.g. eliding RepartitionExec), and the
serialized (proto) wire format are unchanged. There is one display-only
change: EXPLAIN now renders output_partitioning=Hash(...) on DataSourceExec
for partition-grouped scans. The scan already produced that partitioning before
(it was derived lazily inside output_partitioning()); it is now stored on the
output_partitioning field and therefore shown. The
repartition_subset_satisfaction and preserve_file_partitioning slt expected
plans are updated accordingly.

cargo-semver-checks will flag the removals as breaking, which is expected for
this cleanup.